1. Field of the Invention
This invention relates generally to communication between host computer systems and peripheral devices, and more particularly to methods for efficiently communicating with target devices and exception handling in the Intelligent Input/Output (I.sub.2 O) architecture environment.
2. Description of the Related Art
In an effort to make computer systems more flexible and better able to expand their functionality, many types of well known computer peripheral devices and software drivers have been developed over the years. For example, peripheral devices may either be internal to a computer system's housing, or be external stand-alone devices. Typical internal peripheral devices include hard disk drives, optical disc drives and the like. Most commonly, external peripheral devices are connected to a computer system via a suitable host adapter card. The host adapter card is typically connected to the host computer system via an internal bus or an external connection providing similar functionality.
The host adapter generally has its own hardware to enable communication to and from the peripheral device. The peripheral devices, in turn, are specific to a particular type of communication protocol. One common type of protocol is the SCSI protocol, which enable many types of high speed SCSI peripheral devices to communicate data to and from the host computer. Although computer systems have been gaining additional uses, functionality and modularity, these added features do have the downside of placing a burden on the host computer's CPU.
As a result, microprocessor vendors, such as Intel Corporation of Santa Clara, Calif., have developed specialty I/O processors that are configured to offload some of the processing burden from the CPU of the host computer. Although the host computer has been spared of some processing responsibilities by implementing these specialty microprocessors, adding this type of additional hardware does have the downside of increasing the cost of an overall system.
To facilitate discussion, FIG. 1 illustrates a prior art interface between a host computer system 100 and a peripheral device 118. The simplified architecture of FIG. 1 is commonly used to implement the intelligent I/O (I.sub.2 O) architecture communication specification, which was jointly developed by several computer vendors, and is currently available from The I.sub.2 O Special Interest Group (SIG) of San Francisco, Calif. The I.sub.2 O Specification is hereby incorporated by reference in its entirety. The I.sub.2 O specification, in general, defines a standard architecture that is independent of the device being controlled. Thus, implementing the I.sub.2 O architecture has the power of enabling developers to design cross-platform intelligent I/O devices and software drivers. Accordingly, device manufacturers only need to write a single I.sub.2 O-ready driver for each device, irrespective of the operating system that will ultimately communicate with the I.sub.2 O device driver. Each operating system vender (OSV) must write their own drivers for storage, for LAN, etc.
The I.sub.2 O architecture is designed to work in conjunction with an input/output processor 106. The input/output processor 106 generally communicates across a PCI interface 104, to communicate with a block storage operating system module (OSM) 102. The block storage OSM 102 is configured to communicate I.sub.2 O message requests to the I/O processor 106, which is then configured to implement a real-time operating system (OS) 108 to execute a device driver 110 (i.e., the target device having a target ID "TID").
The device driver 110 then communicates with a desired SCSI chip 116, for example, via a signal 112. The signal 112 represents the desired request that may be made to the SCSI chip 116 and thus communicated to the peripheral device 118. By way of example, in the case of peripheral storage devices, the request provided through signal 112 may be a request to read a certain number of data blocks from the peripheral storage device 118. Once the desired data has been read from the peripheral storage device 118, the data may be transferred to memory and a reply signal 114 may be provided back to the device driver 110, indicating that a successful data transfer has occurred (or alternatively, indicating that some type of error occurred). The device driver 110 is therefore a logical entity that responds as a target ID (TID). In general, the input/output processor 106 uses the real-time OS 108 to operate on the device driver 110 and communicate with the SCSI chip 116 without utilizing the host computer's processor. For more information on I/O processor functionality, reference may be made to U.S. Pat. Nos. 5,751,975 and 5,734,847, both of which are hereby incorporated by reference.
Although implementing an input/output processor 106 and associated hardware will enable proper handling of I.sub.2 O messaging from the block storage OSM 102, this implementation has the downside of significantly increasing the cost of implementing the I.sub.2 O architecture messaging scheme to simply effectuate communication with the target device driver 110. Therefore, when I.sub.2 O architecture messaging is desired, a user of a computer system will be required not only to purchase, for example, the correct SCSI host adapter card, but also to purchase a specialty input/output processor 106 and associated hardware. As mentioned above, implementing this amount of added hardware has the downside of increasing the total package cost of communicating with peripheral devices.
In spite of the fact that earlier generation computer systems lacked sufficient processor power to handle additional processing tasks, as processor speeds in common computer systems have continued to increase, the need for auxiliary processors is diminishing. That is, the added processing needed to communicate I.sub.2 O messages from a host computer system to a target device no longer places such a great processing burden on the processor of the host computer system.
In view of the foregoing, there is a need for a computer implemented method and system that will enable I.sub.2 O architecture messaging and exception handling between a host computer system and a target device, without unnecessarily increasing a system's cost by requiring specialty processors.